RFC1188 DS Oct 90 A Proposed Standard for the Transmission of IP
Datagrams over FDDI Networks
RFC1390 S Jan 93 Transmission of IP and ARP over FDDI Networks
FDDI MIB (fddimib)
Charter
Chair(s):
Jeffrey Case <case@cs.utk.edu>
Network Management Area Director(s)
J.R. Davin <davin@bellcore.com>
Mailing lists:
General Discussion:fddi-mib@CS.UTK.EDU
To Subscribe: fddi-mib-request@CS.UTK.EDU
Archive:
Description of Working Group:
The FDDI MIB Working Group is chartered to define a MIB for FDDI
devices that is consistent with relevant FDDI specifications produced
by ANSI. All definitions produced by this Working Group will be
consistent with the SNMP network management framework and other
internet-standard MIBs for SNMP.
Goals and Milestones:
Done ``Final'' initial draft of required get/set variables.
Done Initial implementations of required get/set variables.
Done Revised ``final'' draft of required get/set variables.
Done Adoption of draft of required get/set variables.
Mar 92 Submit the FDDI MIB to the IESG for consideration as a Proposed or
Draft Standard depending on the magnitude of changes to RFC 1285.
Done Hold a meeting at the November IETF Plenary.
Dec 92 Post an Internet-Draft aligned with current the current ANSI document
factoring in implementation experience with RFC 1285.
Host Resources MIB (hostmib)
Charter
Chair(s):
Steven Waldbusser <waldbusser@andrew.cmu.edu>
Network Management Area Director(s)
J.R. Davin <davin@bellcore.com>
Mailing lists:
General Discussion:hostmib@andrew.cmu.edu
To Subscribe: hostmib-request@andrew.cmu.edu
Archive:
Description of Working Group:
The Host Resources MIB Working Group is chartered to produce exactly
one document that defines SNMP MIB objects that instrument
characteristics common to all internet hosts. The goal of this work is
to address the urgent operational need in the internet community for
management of host systems. Owing to this urgency, the Working Group
will focus exclusively on the alignment of existing MIB technology in
order to achieve common solutions in a timely manner.
For purposes of this effort, the term ``internet host'' is construed to
mean any computer that communicates with other similar computers
attached to the internet and that is directly used by one or more human
beings. Although the work of the Group does not necessarily apply to
devices whose primary function is communications services (e.g.,
terminal servers, routers, bridges, monitoring equipment), such
relevance is not explicitly precluded. The single MIB produced shall
instrument attributes common to all internet hosts including, for
example, both personal computers and systems that run variants of
Unix.
The methodology of this Working Group is to focus entirely on the
alignment of existing, enterprise-specific MIBs for SNMP that are
relevant to its task. The Group will work towards its goal by
distillation and generalization of these existing MIBs into a single,
common MIB definition.
Owing to the urgent operational need for managing host systems, this
effort will not be comprehensive in scope. Rather, the MIB produced by
this Group will be confined to critical information about hardware and
software configuration, processor and memory use, and data storage
capacities, backup, and use.
Owing to the lack of a well-understood and accepted architecture, the
Working Group will not address in any way, mechanisms that could be used
to monitor or control the use of licensed software products.
All definitions produced by the Group will be consistent with the SNMP
network management framework and all other internet-standard MIBs for
SNMP. Wherever possible, the definitions produced will make use of or
align with relevant work in progress with chartered working groups of
the IETF. Also, wherever possible, the Working Group will take into
consideration pre-existing, stable work produced by other, accredited
standards bodies.
Goals and Milestones:
Done First Working Group meeting. Discuss the initial proposed document.
Done Post an Internet-Draft describing the Host Resources MIB.
Done Hold an interim meeting to discuss the current document.
Done Meet at the IETF plenary to identify changes necessary for Working
Group closure.
Dec 92 Submit the Host Resources MIB to the IESG as a Proposed Standard.
IEEE 802.3 Hub MIB (hubmib)
Charter
Chair(s):
Keith McCloghrie <kzm@hls.com>
Donna McMaster <mcmaster@synoptics.com>
Network Management Area Director(s)
J.R. Davin <davin@bellcore.com>
Mailing lists:
General Discussion:hubmib@synoptics.com
To Subscribe: hubmib-request@synoptics.com
Archive: sweetwater.synoptics.com"~/pub/hubmib
Description of Working Group:
This Working Group will produce a document describing MIB objects for
use in managing Ethernet-like hubs. A hub is defined as a multiport
repeater that conforms to Section 9, ``Repeater Unit for 10 Mb/s
Baseband Networks'' in the IEEE 802.3/ISO 8802-3 CSMA/CD standard (2nd
edition, Sept. 1990). These Hub MIB objects may be used to manage
non-standard repeater-like devices, but defining objects to describe
vendor-specific properties of non-standard repeater-like devices are
outside the scope of this Working Group. The MIB object definitions
produced will be for use by SNMP and will be consistent with other SNMP
objects, conventions, and definitions.
In order to minimize the instrumentation burden on managed agents, the
MIB definitions produced by the Working Group will, wherever feasible,
be semantically consistent with the managed objects defined in the IEEE
draft standard P802.3K, ``Layer Management for Hub Devices.'' The
Working Group will base its work on the draft that is the output of the
July 1991 IEEE 802 plenary meeting. The Working Group will take
special cognizance of Appendix B of that specification that sketches a
possible realization of the relevant managed objects in the SNMP
idiom.
Consistent with the IETF policy regarding the treatment of MIB
definitions produced by other standards bodies, the Working Group may
choose to consider only a subset of those objects in the IEEE
specification and is under no obligation to consider (even for
``Optional'' status) all objects defined in the IEEE specification.
Moreover, when justified by special operational needs of the community,
the Working Group may choose to define additional MIB objects that are
not present in the IEEE specification.
Although the definitions produced by the Working Group should be
architecturally consistent with MIB-II and related MIBs wherever
possible, the Charter of the Working Group does not extend to
perturbing the conceptual models implicit in MIB-II or related MIBs in
order to accommodate 802.3 Hubs. In particular, to the extent that the
notion of a ``port'' in an 802.3 Hub is not consistent with the notion
of a network ``interface'' as articulated in MIB-II, it shall be
modelled independently by objects defined in the Working Group.
Because the structure of 802.3 Hub implementations varies widely, the
Working Group shall take special care that its definitions reflect a
generic and consistent architectural model of Hub management rather
than the structure of particular Hub implementations.
The IEEE Hub Management draft allows an implementor to separate the ports in a hub into groups, if desired (i.e., a vendor might choose to represent field-replaceable unites as groups of ports so that the port numbering would match a modular hardware implementation.) Because the Working Group Charter
does not extend to consideration of fault-tolerant, highly-available systems
in general, its treatment of these groups of ports in an 802.3 Hub (if any)
shall be specific to Hub management and without impact upon other portions of
the MIB.
The Working Group is further chartered at its discretion to define an
SNMP MIB for management of IEEE 802.3 Medium Access Units (MAUs). An
802.3 Medium Attachment Unit (MAU) attaches a repeater port or
Ethernet-like interface to the local network medium. The scope of this
work may include several types of MAU units: 10BASE5 (thick coax),
10BASE2 (thin coax), 10BASE-T (twisted pair), FOIRL and 10BASE-F (fiber
optic). Managed objects defined as part of the MAU MIB task may, for
example, represent such information as MAU type, link status, and
jabbering indications.
Goals and Milestones:
Done Distribute first draft of documents and discuss via E-mail.
Done Working Group meeting as part of IETF to review documents.
Done Distribute updated documents for more E-mail discussion.
Done Review all documents at IETF meeting. Hopefully recommend
advancement with specified editing changes.
Done Documents available with specified changes incorporated.
Done Submit the Repeater MIB to the IESG for consideration as a Proposed
Standard.
Nov 92 Post the Media Access Unit MIB Definition as an Internet-Draft.
Apr 93 Submit the Media Access Unit MIB to the IESG for consideration as a
Proposed Standard.
Internet Anonymous FTP Archives (iafa)
Charter
Chair(s):
Peter Deutsch <peterd@bunyip.com>
Alan Emtage <bajan@bunyip.com>
User Services Area Director(s)
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:iafa@cc.mcgill.ca
To Subscribe: iafa-request@cc.mcgill.ca
Archive: archive.cc.mcgill.ca:~/pub/iafa-archive
Description of Working Group:
The Internet Anonymous FTP Archives Working Group is chartered to
define a set of recommended standard procedures for the access and
administration of anonymous ftp archive sites on the Internet. Such a
set of procedures will provide a framework for:
(a) Allowing the inexperienced Internet user the ability to more
easily navigate the hundreds of publically accessible archive sites.
(b) Allowing users and network-based tools to retrieve specific site
information such as access policies, contact information, possible
areas of information specialization, archived package descriptions, etc.,
in a standardized manner.
Particular emphasis will be placed on the possible impact of these
procedures on the FTP site administrators.
Attention will be paid to the impact of newer archive indexing and
access tools on the operation of such archive sites. A set of
suggestions will be offered to allow archive site administrators to
better integrate their offerings with such tools as they are
developed.
The security of the anonymous FTP site configuration will also be
considered to be an integral part of this document. It is expected
that remote management of the archives will be adequately handled by
existing network management procedures.
Goals and Milestones:
Done First IETF Meeting: review and approve the Charter making any changes
deemed necessary. Examine the scope of the recommended procedures and
impact on site administrators. Assign writing assignments for the
first draft of the documents.
Mar 92 Review first draft and determine necessary revisions. Follow up
discussion will occur on mailing list.
Jun 92 Make document an Internet-Draft. Continue revisions based on comments
at IETF and on the mailing list.
Nov 92 Fourth IETF meeting. Review final drafts and if OK, give to IESG for
The IP over Large Public Data Networks Working Group will
specify the operation of the TCP/IP protocol suite over Public Data
Networks (PDNs) such as SMDS, ISDN, X.25 PDNs, and Frame Relay. The
Working Group will develop and define algorithms for the resolution of
IP addresses and for the routing of IP datagrams over large,
potentially global, public data networks.
The IP over SMDS Working Group has defined the operation of the
Internet protocols when SMDS is used to support relatively small
virtual private networks, or Logical IP Subnets (LISs). Issues
arising from public and global connectivity were delegated to the
IPLPDN Working Group.
The IPLPDN Working Group will also continue the work of the Private Data Network
Routing Working Group (PDNROUT) on X.25 PDNs. This work will be
extended to include call management and the use of the ISDN B channels
for the transport of IP datagrams.
Address resolution and routing over Frame Relay will also be
discussed.
Goals and Milestones:
Address resolution of Internet addresses to SMDS E.164
addresses, to ISDN E.164 addresses, to X.121 addresses,
and to Frame Relay Data Link Connection Identifiers (DLCIs).
The algorithm(s) may be defined in either a single or in multiple
documents.
Routing of IP datagrams across very large internets implemented
SMDS and on other PDNs.
Management of ISDN and of X.25 connections and the use
of the ISDN B and D channels.
Done Establish priorities and dates of completion for documents.
Internet Protocol Security Protocol (ipsec)
Charter
Chair(s):
Al Hoover <hoover@ans.net>
Paul Lambert <paul_lambert@email.mot.com>
Security Area Director(s)
Steve Crocker <crocker@tis.com>
Mailing lists:
General Discussion:ipsec@ans.net
To Subscribe: ipsec-request@ans.net
Archive: ftp.ans.net:~/pub/archive/ipsec
Description of Working Group:
Rapid advances in communication technology have accentuated the need
for security in the Internet. The IP Security Protocol Working Group
(IPSEC) will develop mechanisms to protect client protocols of IP.
A security protocol in the network layer will be developed to provide
cryptographic security services that will flexibly support combinations
of authentication, integrity, access control, and confidentiality. The
protocol formats for the IP Security Protocol (IPSP) will be independent of
the cryptographic algorithm. The preliminary goals will specifically
pursue host-to-host security followed by subnet-to-subnet and host-to-
subnet topologies.
Protocol and cryptographic techniques will also be developed to support
the key management requirements of the network layer security. The key
management will be specified as an application layer protocol that is
independent of the lower layer security protocol. The protocol will
initially support public key based techniques. Flexibility in the
protocol will allow eventual support of Key Distribution Center (KDC -
such as Kerberos) and manual distribution approaches.
Goals and Milestones:
Mar 93 Post as an Internet-Draft the IP Security Protocol.
Jul 93 Post as an Interenet-Draft the specification for Internet Key
Management.
Nov 93 Report on Pilot Implementation of the IP Security Protocol. Update
Protocol as needed.
Mar 94 Report on Pilot implementation of the Internet Key Management
Protocol. Update Internet-Draft as needed.
Jul 94 Submit the IP Security Protocol to the IESG for consideration as a
Proposed Standard.
Jul 94 Submit the Key Management Protocol to the IESG for consideration as a
Proposed Standard.
ISIS for IP Internets (isis)
Charter
Chair(s):
Ross Callon <callon@wellfleet.com>
Routing Area Director(s)
Bob Hinden <hinden@eng.sun.com>
Mailing lists:
General Discussion:isis@merit.edu
To Subscribe: isis-request@merit.edu
Archive:
Description of Working Group:
The IETF ISIS Working Group will develop additions to the existing
OSI IS-IS Routing Protocol to support IP environments and dual (OSI
and IP) environments.
Goals and Milestones:
Done Liaison with the IS-IS editor for OSI in case any minor changes to
IS-IS are necessary.
Done Develop an extension to the OSI IS-IS protocols which will allow use
of IS-IS to support IP environments, and which will allow use of
IS-IS as a single routing protocol to support both IP and OSI in dual
environments.
Done Post a revision of the IS-IS as an Internet-Draft.
Mar 93 Submit the revised IS-IS to the IESG as a Draft Standard.
Mar 93 Submit the IS-IS MIB to the IESG as a Proposed Standard.
Internet School Networking (isn)
Charter
Chair(s):
John Clement <clement@educom.edu>
Arthur St. George <stgeorge@bootes.unm.edu>
Connie Stout <cstout@tenet.edu>
User Services Area Director(s)
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:isn-wg@unmvma.unm.edu
To Subscribe: listserv@unmvma.unm.edu body: sub isn-wg <name>
Archive:
Description of Working Group:
The Internet School Networking Working Group is chartered to
facilitate the connection of the United States' K-12
(Kindergarten-12th Grade) schools, public and private, to the
Internet, and school networking in general.
It is critically important that national networking for K-12 education
proceed along established lines of protocol, using existing network
structures. The Working Group's first priority will be to establish
guidelines for specialized user interfaces. K-12 networking will also
require other support services, such as directories, online and
hotline help, specialized training programs and collaborative projects
with instructional and curriculum groups, disciplinary groups and
postsecondary institutions.
While the initial focus is school networking in the U.S., the Working
Group will coordinate its efforts with similar activities in other
countries and regions of the world.
Goals and Milestones:
Done Meet for the first time at IETF and establish approval of Charter.
Examine the status of projects in process when Working Group was
created. Begin work on list of deliverables.
Jan 92 Release X.500 ``K-12 People Directory'' version in collaboration with
Merit. Develop plans and milestones for K-12 Resources Directory.
Mar 92 First draft of information packet document for computing directors to
assist them in connecting K-12 schools. First draft of user
interface guideline statement.
May 92 Release X.500 K-12 Resource Directory version in collaboration with
Merit. Present final draft guideline statement.
Internet User Population (iup)
Charter
Chair(s):
Craig Partridge <craig@bbn.com>
User Services Area Director(s)
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:ietf@venera.isi.edu
To Subscribe: ietf-request@venera.isi.edu
Archive:
Status: concluded
Description of Working Group:
To devise and carry out an experiment to estimate the size of the
Internet user population.
Goals and Milestones:
Done Prepare an article for publication in a networking magazine.
Done Write a description of the experimental procedure.
Done Write an RFC that gives the results of the experiment.
Internet-Drafts:
No Current Internet drafts.
RFC's:
None to date.
LAN Manager (lanman)
Charter
Chair(s):
David Perkins <dperkins@synoptics.com>
Network Management Area Director(s)
J.R. Davin <davin@bellcore.com>
Mailing lists:
General Discussion:lanmanwg@cnd.hp.com
To Subscribe: lanmanwg-request@cnd.hp.com
Archive:
Status: concluded
Description of Working Group:
This working group is chartered to define and maintain the MIB and
relevant related mechanisms needed to allow management of workgroup
PCs and servers that are using the Microsoft Lan Manager protocols.
These protocols provide file and print service and mechanisms for
development of application server-client systems such as ones for mail
or SQL database.
Goals and Milestones:
Define an upwards compatible MIB for LAN Manager version 2.x.
Work to influence Microsoft, the developer of LAN Manager, to
add/change APIs so that MIB developed can be consistant in style
and information content with MIBs developed by other MIB Working
Groups.
Internet-Drafts:
No Current Internet drafts.
RFC's:
None to date.
Automated Internet Mailing List Services (list)
Charter
Chair(s):
David Lippke <lippke@utdallas.edu>
Applications Area Director(s)
Russ Hobby <rdhobby@ucdavis.edu>
Erik Huizer <huizer@surfnet.nl>
Mailing lists:
General Discussion:ietf-list-wg@utdallas.edu
To Subscribe: ietf-list-wg-request@utdallas.edu
Archive: pub/ietf-list-wg@ftp.utdallas.edu
Status: concluded
Description of Working Group:
This Working Group will concern itself with ``list servers'', i.e.,
advanced mail exploders/reflectors which provide services such as
automated subscription, archive maintenance, and coordination with
similar systems on the network.
The Group will initially focus its activities towards establishing a
baseline user interface. Although most current systems support a
command set patterned after Eric Thomas' BITNET LISTSERV, there is
wide variance in the options supported and in the general patterns of
interaction. This results in a great deal of user confusion. The
Working Group's interface definition will address this by establishing
a set of commands, options, interactions, and procedures which will
(hopefully) be supported by all list servers as a subset of their full
repertoire.
As a part of the user interface work, the Group will also define an
authentication service for users' list server transactions. Toward
this end, and to address the privacy issue, the Group will consult
with the Security Area Advisory Group (SAAG).
The second phase of the Group's work will be to provide for the
interconnection and coordination of list servers. Experience with the
BITNET LISTSERV has shown that it is important for users be able to
view the collection of list servers on the network as an integrated
whole. Ideally, users should only have to deal with their local
mailing list service---which knows where all public lists are, what
they are, and is able to act on the user's behalf with respect to
them. Interconnecting list servers allows this ``integrated user view''
to be created and also lets issues such as traffic minimization,
timely distribution, and load sharing to be more easily addressed.
Consequently, the Working Group will define the conceptual models,
communication methods, and extensions to prior work which are
necessary to bring this interconnection and coordination about.
It is anticipated that further work on issues of authentication and
privacy will continue in parallel with the ``integration'' effort ---
perhaps manifesting itself as a separate RFC which extends the user
interface definition produced during the first phase.
Goals and Milestones:
Submit interconnection/coordination definition document to the IESG
for publication as a Proposed Standard.
Done Review the Group's Charter and begin work on the user interface
definition.
Nov 91 Resolve outstanding issues with the user interface definition and
prepare document for IESG submission. Begin work to address the
interconnection/coordination issue.
Jan 92 Submit user interface definition document to IESG as a Proposed
Standard.
Mar 92 Focus the interconnection/coordination work. Finalize and document
settled issues.
Internet-Drafts:
No Current Internet drafts.
RFC's:
None to date.
MIME-MHS Interworking (mimemhs)
Charter
Chair(s):
Steve Thompson <sjt@gateway.ssw.com>
Applications Area Director(s)
Russ Hobby <rdhobby@ucdavis.edu>
Erik Huizer <huizer@surfnet.nl>
Mailing lists:
General Discussion:mime-mhs@surfnet.nl
To Subscribe: mime-mhs-request@surfnet.nl
Archive:
Description of Working Group:
MIME, (Multipurpose Internet Mail Extensions) is currently a Proposed Standard. MIME redefines the format of message bodies to allow multi-part textual
and non-textual message bodies to be represented and exchanged without
loss of information. With the introduction of MIME as a Proposed
Standard it is now possible to define mappings between RFC-822
content-types and X.400 body parts. The MIME-MHS Interworking Working Group is
chartered to develop these mappings, providing an emphasis on both
interworking between Internet and MHS mail environments and also on
tunneling through these environments. These mappings will be made in
the context of an RFC-1148bis environment.
Goals and Milestones:
Done Post an Internet-Draft describing MIME-MHS Interworking.
Done Post an Internet-Draft describing the ``core'' set of Registered
conversions for bodyparts.
Jul 92 Submit a completed document to the IESG describing MIME-MHS
Interworking as a Proposed Standard.
Jul 92 Submit the ``core'' bodyparts document to the IESG as a Proposed
Standard.
Multi-Media Bridging (mmb)
Charter
Chair(s):
Jeffrey Fitzgerald <jjf@fibercom.com>
Internet Area Director(s)
Philip Almquist <almquist@jessica.stanford.edu>
Stev Knowles <stev@ftp.com>
Dave Piscitello <dave@eve.bellcore.com>
Mailing lists:
General Discussion:mmbwg@fibercom.com
To Subscribe: mmbwg-request@fibercom.com
Archive:
Status: concluded
Description of Working Group:
The Multi-Media Bridge Working Group has the task of addressing
the function of multi-media bridges within TCP/IP networks. This
is viewed as necessary at this time because of the proliferation
of these devices.
The first goal of the Group is to document the multi-media bridge
technology and point out the issues raised by having these devices
in a TCP/IP internet. If there are problems which can be addressed
the Group will work towards resolving them and documenting the
solutions.
Goals and Milestones:
Done Finalize Charter of Group.
Aug 91 Document mulit-media bridging technology and its affect on TCP/IP
Internets.
Aug 91 Document issues to be addressed by Working Group.
The PIP Working Group is chartered to develop an IPv7 proposal using
the basic ideas of Pip as described in the Pip overview.
Pip is designed on one hand to be very general, being able to handle
many routing/addressing/flow paradigms, but on the other hand to allow
for relatively fast forwarding. Pip has the potential to allow for
better evolution of the internet. In particular, it is hoped that we
will be able to advance routing, addressing, and flow techniques
without necessarily having to change hosts (once hosts are running
Pip).
While the Pip overview demonstrates a number of powerful mechanisms,
much work remains to be done to bring Pip to a full specification.
This work includes, but is not limited to: specifying the header
format; specifying a basic set of error messages (PCMP messages);
specifying the Pip forwarding rules; specifying host interface messages
(particularly the directory service query response); specifying rules
for host Pip header construction; specifying modifications to existing
protocols for use with Pip (BGP IV, OSPF, ARP, DNS, etc.); specifying
Pip MAX MTU Discovery techniques; and specifying a transition strategy
for Pip.
Over the near-term, the goal of the PIP Working Group will be to produce these
specifications and supporting documentation. Over the long-term, up to
the point where Pip is definitively rejected as IPv7, it is expected
that the PIP Working Group will oversee implementations and testing of the Pip
specifications.
Except to the extent that the PIP Working Group modifies existing protocols for
operation with Pip, and to the extent that the PIP Working Group must be aware of routing/addressing/flow architectures to really make Pip general, the
PIP Working Group will not work on routing/addresing/flow architectures.
Goals and Milestones:
Done Review and approval of the Charter for the PIP Working Group.
Done Post as an Internet-Draft a description of the Pip Packet Format and
Forwarding Engine, the Pip Control Message Protocol (PCMP), the Pip
Host Interface Message Protocol, and the Pip MTU Discovery Protocol.
Oct 92 Post as an Internet-Draft a description of the modifications to BGP
IV for Pip, the Modifications to OSPF for Pip, the modifications to
DNS for Pip, the modifications to ARP for Pip, the Address assignment
in Pip, and the Pip transition strategy.
Done Presentation and review of the PIP specification by the IESG. If
acceptable, the first Working Group meeting will be held.
Process for Organization of Internet Standards (poised)
Charter
Chair(s):
Steve Crocker <crocker@tis.com>
Not Assigned to an Area Director(s)
<>
Mailing lists:
General Discussion:poised@nri.reston.va.us
To Subscribe: poised-request@nri.reston.va.us
Archive: cnri.reston.va.us:~/poised/current
Description of Working Group:
The goal of this Working Group is to examine the Internet
standards process and the responsibilities of the IAB, with
attention to the relationship between the IAB and IETF/IESG.
The need for this Working Group was suggested during discussions
at the July 1992 IETF. This led to a request from the Internet
Society president to form such a Working Group.
The Working Group will consider the following matters:
1. Procedures for making appointments to the Internet
Architecture Board.
2. Procedures for resolving disagreements among IETF, IESG and
IAB in matters pertaining to the Internet Standards.
3. Methods for assuring that for any particular Internet
Standard, procedures have been followed satisfactorily by all
parties so that everyone with an interest has had a fair
opportunity to be heard.
The Working Group will begin with a review of the procedures for making
IAB appointments as documented in RFC 1358 and a review of
the standards-making process documented in RFC 1310.
The Working Group has a goal of issuing a final report in time for IESG
consideration and publication as an RFC before the ISOC Board Trustee's
meeting in December 1992. Given the compressed timescale, the Working
Group will conduct most of its deliberations by electronic mail on the
POISED Working Group mailing list. There will also be a preliminary
report and discussions at the November 1992 IETF meeting in Washington,
DC.
This will be a normal IETF Working Group, i.e., the mailing list and all
discussions will be completely open.
Goals and Milestones:
Done Review and approval of the Charter for the POISED Working Group.
Done Gather initial set of issues and write a preliminary report.
Oct 92 Post as an Internet-Draft the initial recommendations to the ISOC
Board.
Done Open discussion and presentation of the work of the POISED Working
Group at Washington D.C. IETF meeting.
Dec 92 Submit the recommendations document to the IESG for posting as an
Informational RFC. This document will be subsequently transmitted to
the ISOC Board.
Point-to-Point Protocol Extensions (pppext)
Charter
Chair(s):
Brian Lloyd <brian@lloyd.com>
Internet Area Director(s)
Philip Almquist <almquist@jessica.stanford.edu>
Stev Knowles <stev@ftp.com>
Dave Piscitello <dave@eve.bellcore.com>
Mailing lists:
General Discussion:ietf-ppp@ucdavis.edu
To Subscribe: ietf-ppp-request@ucdavis.edu
Archive:
Description of Working Group:
The Point-to-Point Protocol (PPP) was designed to encapsulate multiple
protocols. IP was the only network layer protocol defined in the
original documents. The Working Group is defining the use of other
network level protocols and options for PPP. The Group will define the
use of protocols including: bridging, ISO, DECNET (Phase IV and V),
XNS, and others. In addition it will define new PPP options for the
existing protocol definitions, such as stronger authentication and
encryption methods.
Goals and Milestones:
Router Discovery (rdisc)
Charter
Chair(s):
Steve Deering <>
Internet Area Director(s)
Philip Almquist <almquist@jessica.stanford.edu>
Stev Knowles <stev@ftp.com>
Dave Piscitello <dave@eve.bellcore.com>
Mailing lists:
General Discussion:gw-discovery@gregorio.stanford.edu
To Subscribe: gw-discovery-request@gregorio.stanford.edu
Archive:
Status: concluded
Description of Working Group:
The Router Discovery Working Group is chartered to adopt or develop a
protocol that Internet hosts may use to dynamically discover the
addresses of operational neighboring gateways. The group is expected
to propose its chosen protocol as a standard for gateway discovery in
the Internet.
The work of this group is distinguished from that of the Host
Configuration Working Group in that this group is concerned with the
dynamic tracking of router availability by hosts rather than the
initialization of various pieces of host state (which might include
router addresses) at host-startup time.
Goals and Milestones:
Ongoing Gather implementation and operational experience, revise the
specification to reflect lessons learned, and submit the protocol for
Draft Standard.
Done Created Working Group; established and advertised mailing list.
Initiated email discussion to identify existing and proposed
protocols, for router discovery.
Done Held first meeting in Palo Alto. Reviewed 9 candidate protocols, and
agreed on a hybrid of cisco's GDP and an ICMP extension proposed by
Deering.
Done Held second meeting in Tallahassee. Reviewed the proposed protocol
and discussed a number of open issues.
Done Held third meeting in Pittsburgh. Discussed and resolved several
issues that had been raised by email since the last meeting. Draft
specification of router discovery protocol to be ready by next
meeting. Experimental implementations to be started.
Done Meet in Vancouver. Review draft specification, and determine any
needed revisions. Evaluate results of experimental implementations
and assign responsibility for additional experiments, as required.
Submit the specification for publication as a Proposed Standard
shortly after the meeting.
Done Revise specification as necessary, based on field experience. Ask
the IESG to elevate the protocol to Draft Standard status. Disband.
The User Services Working Group provides a regular forum for people
interested in user services to identify and initiate projects designed
to improve the quality of information available to end-users of the
Internet. (Note that the actual projects themselves will be handled
by separate groups, such as IETF working groups created to perform certain
projects, or outside organizations such as SIGUCCS.
(1) Meet on a regular basis to consider projects designed to improve services
to end-users. In general, projects should:
- Clearly address user assistance needs;
- Produce an end-result (e.g., a document, a program plan, etc.);
- Have a reasonably clear approach to achieving the end-result
(with an estimated time for completion);
- Not duplicate existing or previous efforts.
(2) Create working groups or other focus groups to carry out projects deemed
worthy of pursuing.
(3) Provide a forum in which user services providers can discuss and identify
common concerns.
Goals and Milestones:
Ongoing This is an oversight group with continuing responsibilities.
Whois and Network Information Lookup Service (wnils)
Charter
Chair(s):
Joan Gargano <jcgargano@ucdavis.edu>
User Services Area Director(s)
Joyce Reynolds <jkrey@isi.edu>
Mailing lists:
General Discussion:ietf-wnils@ucdavis.edu
To Subscribe: ietf-wnils-request@ucdavis.edu
Archive: ucdavis.edu:~/pub/ietf-wnils-archive
Description of Working Group:
The Network Information Center (NIC) maintains the central NICNAME
database and server, defined in RFC 954, providing online look-up of
individuals, network organizations, key nodes, and other information
of interest to those who use the Internet. Other distributed
directory information servers and information retrieval tools have
been developed and it is anticipated more will be created. Many sites
now maintain local directory servers with information about
individuals, departments and services at that specific site.
Typically these directory servers are network accessible. Because
these servers are local, there are now wide variations in the type of
data stored, access methods, search schemes, and user interfaces. The
purpose of the Whois and Network Information Lookup Service (WNILS)
Working Group is to expand and define the standard for WHOIS services,
to resolve issues associated with the variations in access and to
promote a consistent and predictable service across the network.
Goals and Milestones:
Done Review and approve the Charter making any changes deemed necessary.
Examine the particular functional needs for expanded whois directory
service. Begin work on a framework for recommendations. Assign
writing assignments for first draft of document.
Done Post the Whois and Network Information Lookup Service Recommendations
document as an Internet-Draft.
Dec 92 Submit the Whois and Network Information Lookup Service
Recommendations document to the IESG as an Informational document.
Dec 92 Post a revised WHOIS protocols specification as an Internet-Draft.
Dec 92 Submit the revised WHOIS protocol documents to the IESG as Draft
Standards.
X.25 Management Information Base (x25mib)
Charter
Chair(s):
Dean Throop <throop@dg-rtp.dg.com>
Network Management Area Director(s)
J.R. Davin <davin@bellcore.com>
Mailing lists:
General Discussion:x25mib@dg-rtp.dg.com
To Subscribe: x25mib-request@dg-rtp.dg.com
Archive: dg-rtp.dg.com:~/x25mib/Current.Mail
Description of Working Group:
This Working Group will produce a set of three documents that describe
the Management Information Base for X.25. The first document will
specify the objects for the X.25 Link Layer. The second document will
specify the objects for the X.25 Packet Layer. The third document will
specify the objects for managing IP over X.25. The Working Group need
not consider the Physical Layer because the ``Definition of Managed
Objects for RS-232-like Hardware Devices'' already defines sufficient
objects for the Physical Layer of a traditional X.25 stack. Any
changes needed at the Physical Layer will be addressed as part of that
activity.
The X.25 object definitions will be based on ISO documents 7776 and
8208 however nothing should preclude their use on other similar or
interoperable protocols (i.e., implementations based on CCITT
specifications).
The objects in the Link and Packet Layer documents, along with the
RS-232-like document, should work together to define the objects
necessary to manage a traditional X.25 stack. These objects will be
independent of any client using the X.25 service. Both of these
documents assume the interface table as defined in MIB-II contains
entries for the Link and Packet Layer interfaces. Thus these documents
will define tables of media specific objects which will have a one to
one mapping with interfaces of ifType ddn-x25, rfc877-x25, or lapb.
The objects for the IP to X.25 convergence functions will be defined
analogously with the ipNetToMedia objects in MIB II.
The Working Group will endeavor to make each layer independent from
other layers. The Link Layer will be independent of any Packet Layer
protocol above it and should be capable of managing an ISO 7776 (or
similar) Link Layer provider serving any client. Likewise the X.25
Packet Layer objects should be independent of the Link Layer below it
and should be capable of managing an ISO 8208 (or similar) Packet Layer
serving any client.
The Working Group will also produce a third document specifying the
objects for managing IP traffic over X.25. These objects will reside
in their own table but will be associated with the X.25 interfaces used
by IP. These objects will not address policy decisions or other
implementation specific operations associated with X.25 connection
management decisions except as explicitly described in existing
standards. These objects will manage the packet flow between IP and
the X.25 Packet Layer specifically including observation of packet
routing and diagnosis of error conditions. Progress on the Link and
Packet Layer documents will not depend on progress of the IP over X.25
document. The IP over X.25 document will proceed on a time available basis after work on the Link and Packet Layer documents and as such the Link and Packet Layers may be completed before the IP over X.25 work.
All documents produced will be for use by SNMP and will be consistent
with other SNMP objects, conventions, and definitions (such as Concise
MIB format). To the extent feasible, the object definitions will be
consistent with other network management definitions. In particular
ISO/IEC CD 10733 will be considered when defining the objects for the
X.25 Packet Layer.
Goals and Milestones:
Done Working Group meeting as part of IETF to review documents.
Done Distribute first draft of documents and discuss via E-mail.
Done Distribute updated documents for more E-mail discussion.
Done Submit the LAPB MIB to the IESG for consideration as a Proposed
Standard.
Done Submit the X.25 Packet Layer MIB to the IESG for consideration as a
Proposed Standard.
Nov 92 Submit the Multiprotocol over X.25 MIB to the IESG for consideration
as a Proposed Standard.
X.400 Operations (x400ops)
Charter
Chair(s):
Alf Hansen <Alf.Hansen@delab.sintef.no>
Tony Genovese <genovese@es.net>
Applications Area Director(s)
Russ Hobby <rdhobby@ucdavis.edu>
Erik Huizer <huizer@surfnet.nl>
Mailing lists:
General Discussion:ietf-osi-x400ops@cs.wisc.edu
To Subscribe: ietf-osi-x400ops-request@cs.wisc.edu
Archive:
Description of Working Group:
X.400 management domains are being deployed today on the Internet. There is a
need for coordination of the various efforts to insure that they can
interoperate and collectively provide an Internet-wide X.400 message transfer
service connected to the existing Internet mail service. The overall goal of
this Group is to insure interoperability between Internet X.400 management
domains and the existing Internet mail service. The specific task of this
Group is to produce a document that specifies the requirements and conventions
of operational Internet PRMDs.
Goals and Milestones:
Done Initial meeting, produce internal outline.
Done Working draft, circulate to interested people.